前言：
最近学习js的时候看到了一段代码，思考再三之后仍然不是很理解，于是决定到尽可能多的平台进行提问，目的有二：1.最主要的，解决问题；2.借这个机会测试哪些平台可以在短时间内给予提问者反馈和援助，从而作为下次提问的首选之地。最后问题是解决了，但是关于提问这件事再次有了不一样的感想。
首先从我自身出发----在中文环境下我能够做到比较规范的提问（我认为的规范），即
- 表诉清晰
- 必要的答谢
但是在英文环境下就显得吃力得多，暴露的缺点如下：
- 表达不够地道清晰，误导了回答者，导致问题被认为是duplicate而被关闭
- 编辑问题后未进行必要的核查，导致了后期的修改
- 无法完全理解对方想要表达的意思
其次从平台出发进行分析，不得不说国内的平台反馈速度和热情的确比不上国外的。知乎因为有邀请机制，所以问题还是有机会得到高手的点拨；SegmentFault本身定位就是中国的Stack Overflow，所以得到专业回答的可能性也比较大。
但是类似贴吧和QQ群这些交流平台，得到有效回答的机率却实在太低。本来QQ群是实时互动的，反馈更应该迅速点，但是很多时候问题会被忽略。是什么原因我就不说了，不好直接下定论，但这无疑提示了我：如果急着解决问题，就应该避免在这些地方浪费时间----一来速度没保障，二来质量参差不齐。
理想的提问平台应该是SegmentFault或者Stack Overflow。关于如何在Stack Overflow规范提问，这里转载一篇不错的博客：
规范提问指南
可以问什么样的主题
大家都知道 Stack Overflow是编程类的问答社区， 但还真有人把它当成通用的问答社区了， 问些完全无关的问题。 其实， Stack Overflow 是有一系列兄弟网站的（目前已经有100+)， 统称 Stack Exchange， 涵盖很多主题， 比如数学、物理、化学等科学类， 服务器管理、Latex、数据库等计算机类， 中文、俄文、日文等语言类， 详细的列表看这里， 不要让好问题问错地方哦。
允许的主题包括： 具体的编程问题、软件算法相关、通常只有程序员用的软件工具相关等。
有些主题是比较容易弄错的， 比如一般的电脑操作问题， 应该去Super User(热门的 Linux/Unix, 和Ubuntu还有独立的站点）， 专业的服务器问题， 应该去Server Fault。这些都不属于编程类的问题， 尽管不少程序员的日常工作也有涉及（想一想“怎么修电脑？”属于编程问题么）。 再举个例子， 同样是编辑器， Vim/Emacs/Atom相关的问题是可以的，因为基本只有程序员会用这些工具， 而 Word/记事本相关的一般就不可以。
什么样的问题应该避免问
编程相关还不够， Stack Overflow 要求问题必须是 「practical, answerable questions based on actual problems that you face」。
这是什么意思呢？ 首先， 开放式的问题是不允许的，比如“你为什么喜欢PHP?”， 隔壁Quora会是更合适的对象。 其次， 问题应该不需要很长的篇幅来回答， 如果一个问题期待的回答足够写一本书， 那很可能会被关闭的。 各种寻求资源的问题应该避免，如 “要完成某某工作， 有什么Python的库可以用”， 或者“学习C++应该选择哪本书？”等， 因为答案会主观， 也容易吸引广告。 最后， 问题不要基于凭空的假设，要基于实际的难题。
需要注意的是，你很可能见过一些违反上面规定的问题还在，而且浏览量很大， 尤其是一些寻求资源的问题， 和非编程相关的计算机问题等。 这是什么原因呢？ 原来，早期的Stack Overflow的规则还比较松，也没有Super User之类的站点。 这些问题往往是08/09年问的，大多数现在已经被关闭了。
上面的规则如果遵守， 你的问题应该问对地方了。 下面继续说说内容上具体需要注意的。
直入主题
Stack Overflow不是论坛， 它的目标是希望成为编程类问答的一个超级数据库， 所以每个问题都不止是为了帮助提问者本人， 更重要的是希望将来能够帮助到每一个遇到同样问题的人。
所以， 和问题无关的内容都被认为是一种噪音， 包括： 打招呼（比如 Hi, Hello， Good afternoon， Dear Coders等)， 表示感谢（比如 Thanks, Any help would be appreciated等)， 没必要的背景（比如 I’m a newbie in C#等)， 你的签名 等。
可能有人会不理解为什么这样规定， 尤其是不要表示感谢这点。 Stack Overflow社区的理由是， 对愿意阅读并尝试解答你问题的人来说， 最好的表达感谢的方式是upvote有帮助的回答， 以及选择其中一个作为答案。 每一句和问题无关的内容都增加了额外的阅读时间， 而一个问题可能会被大量的人阅读。 更多的相关讨论可以参见这里和这里。
同样道理， 当有人回答你的问题之后， 也不要去添加无用的评论， 比如单纯的表达感谢的话， “+1”， 或者闲聊等。 评论的唯一用处是用来澄清疑问。
英语
作为一个英语社区，不论提问、回答还是在评论中和别人互动，都是要用英语的。
除非英语水平真的很糟糕，语法其实并不是最需要担心的，因为并不需要做到完美。Stack Overflow 是允许自由的编辑其他人的问题/回答的（编辑者如果rep不到2K，需要经过评审才会生效）。 有很多人会热情的对问题进行编辑的， 包括修复可能的语法错误。 我想说的一点是， 要尽可能的保证单词拼写是正确的。 即使对英语不够好的人来说， 这也只需要多花一点时间检查就可以做到， 但它代表着对阅读你问题的人的尊重。 甚至很多英语母语的人在拼写上也不注意， 会把I’m 写成im, 把 want to写成 wanna之类的非正式英语， 这些都会降低问题被回答的概率。
内容
在发问题之前， 问自己几个问题：
- 你做过足够的研究么？ 有的人连入门指南都没读上10分钟就去提问， 问的问题能有多少价值呢？
- 你尝试过搜索么？ 至少要试过Google和站内搜索， 很可能相同的问题已经有答案了
- 你试过debug么？ 把你的想法或调试过程写在问题里，否则很可能会看到几条评论“Have you tried anything?”或“We don’t do your homework”之后问题就被downvote得惨不忍睹了。 因为大多数人是拒绝回答没有努力尝试的提问者的。
标签： 一个问题可以加1~5个标签， 大多数问题是和某种具体的编程语言相关的， 这个语言的标签通常是必须的， 否则相关语言的关注者们很可能根本见不到问题。
起一个好标题： 一般来说， 标题应该尽量用简介的语言描述具体的问题。 比如 C# number confusion就是个反例， 如果改成 Why does using float instead of int give me different results when all of my inputs are integers? 就要具体多了。
提供代码
对于编程类问题，的确有问题不需要代码也能表达清楚的， 但大多数问题都需要代码才能清晰的表达。“我声明了一个变量， 调用了几个函数， 然后它的值就变了， 为什么呢？” 这样的问题， 鬼才知道答案。
提供代码要注意： 不要贴截图， 难道你要回答者去照着截图敲键盘复现你的问题？ 也不要只贴站外的链接， 如果站外链接能够提供一些额外的方便功能， 也要在贴代码的基础上附上该链接。
对于提供什么样的代码， Stack Overflow给出了一个可参考的标准： MCVE， 即Minimal, Complete, and Verifiable example
- Minimal: 最小的， 也就是尽可能的去掉和问题无关的部分。 如果你贴了一个几百行的代码， 很少有人愿意花时间去仔细看。 构造最小化例子的过程本身也是debug的过程。
- Complete: 完整的， 一个简单的判断是：别人看到问题， 可以通过复制你提供的代码复现出问题吗？
- Verifiable: 可验证， 描述问题尽可能具体， “the code doesn’t work”这样的描述就很不好。 如果编译不过， 要加上编译错误信息； 如果运行报错， 也同样要加上具体的错误信息； 如果结果和你的预期不一致， 要说清楚你的预期结果是什么， 为什么会这样想。
格式
Stack Overflow的编辑器是Markdown格式的， 如果你还不熟悉， 建议去学一下， 因为Markdown真的是一个只要10分钟就可以学会的语言。
大多数的格式问题都是出在贴代码的地方， 如果你发现你的代码是普通文本， 而没有语法高亮等功能， 那你很可能是格式搞错了。 最方便的方法就是选择所有代码， 然后按键盘Ctrl + K 即可。
交流
有可能你的问题几分钟内就会有人回答， 也有可能有人对问题有疑问， 在评论中要求你解释。 可以评论@他们解释， 如果问题确实不够清晰， 编辑你的问题吧。 最后， 如果你自己发现了解答方法， 而还没人给出， 那就自己回答自己的问题吧。 自问自答是被鼓励的行为。
术语词汇
另外，我认为规范提问建立在规范词汇的基础上，诚如上面所说的，这是一种对回答者应有的尊重。如何积累规范的词汇？我的计划是每周阅读1到2篇MDN上的文档，首先阅读英文并做出自己的理解，之后借助本地化团队的译文加深/修正自己的理解，这个过程既锻炼了阅读技术文档的能力，也可以顺带积累术语词汇，值得尝试。
2019.5.3 更：
近期找到了一个更好的平台（掘金翻译计划），它拥有完善的流程把控和工作分配，这其实正是我很久以前试图在汉化工作中寻找但是没有找到的东西。其实这是一件值得长期投资的事情：
1.最主要的目的，锻炼阅读英文技术文档的能力，同时积累术语词汇；
2.熟悉 github 的操作
3.据说 200 积分可以换一台kindle（虽然听起来遥遥无期，但是可以作为动力哈哈哈）
当然，这个工作不会很轻松，不过完事开头难是很正常的，希望我可以坚持下去吧。